Real-time audio presentations given over the Internet are becoming increasingly popular. Digital audio data sent over the Internet is delivered in a compressed, packetized form, and each packet must be received, decompressed, and then played back by a listener's computer. If any audio packet is not received, decompressed, and sent to playback before the immediately preceding packet has played to completion, there will be an audible break in the audio.
Because data flow over computer networks is inherently inconsistent, packets can be transmitted at a rate slightly different from a rate at which the audio is generated by a sender. “Jitter” is generally a lag time between the actual and expected arrival times of an audio data packet relative to a prior packet, and the occurrence of jitter results in audible breaks or degraded sound quality.
In a non-real-time application, the effect of jitter can be corrected by buffering audio data for several seconds or several minutes before starting playback. Timeliness is not critical for non-real-time applications. Unfortunately, such a lengthy buffering period is not suitable for “real-time” applications in which audio must be delivered in a very timely fashion. For example, a buffering period of even a few seconds can make a conversation awkward, and a long buffering period would significantly impair the ability to effectively converse. Real-time applications strive to make each step of audio capture and playback as fast as possible, thus leading to a much smaller tolerance for the variance in delivery times of audio packets. If audio data is rendered as soon as it is received, the audio heard will contain audible skips and clicks.
While buffering methods according to the prior art provide a number of advantageous features, they nonetheless have certain limitations. The present invention seeks to overcome certain drawbacks of the prior art and to provide new features not heretofore available.